-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GH-15233: [C++] Fix CopyFiles when destination is a FileSystem with background_writes #44897
GH-15233: [C++] Fix CopyFiles when destination is a FileSystem with background_writes #44897
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good on the principle.
By the way, this seems based on a rather old version of git main, can you update?
1294e38
to
dbefb7e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I rebased on the latest main and I think I've addressed all the comments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the update! Here are some more comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, let's wait for CI
@github-actions crossbow submit -g cpp |
This comment was marked as outdated.
This comment was marked as outdated.
Hmm, it looks like we'll either have to fix the serial executor to also take priorities into account (if that's at all possible?), or simply disable the priority test when threading is disabled. |
I think we can implement priorities exactly the same on |
I think it would at least require making the constructor of |
Co-authored-by: Antoine Pitrou <[email protected]>
697c747
to
7573d11
Compare
@pitrou do you have any opinion on extra tests for priorities in |
93c00e9
to
7573d11
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, just a nit
@github-actions crossbow submit -g cpp |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, it looks like there are some bits that I missed when converting |
Ok, this time I managed to test it locally |
@github-actions crossbow submit -g cpp |
Revision: 5774bf2 Submitted crossbow builds: ursacomputing/crossbow @ actions-372e4c30db |
Thanks for triggering the extra tests again. That run is looking better but it looks like a couple failed because of a timeout downloading a dependency
Presumably this is not related to me changes. |
Yes, I've restarted those CI builds. |
Ok, thanks a lot for doing this @Tom-Newton ! |
Thanks for reviewing |
After merging your PR, Conbench analyzed the 3 benchmarking runs that have been run so far on merge-commit 894f5fb. There were no benchmark performance regressions. 🎉 The full Conbench report has more details. It also includes information about 8 possible false positives for unstable benchmarks that are known to sometimes produce them. |
Rationale for this change
Currently it deadlocks when trying to upload more files than we have IO threads.
What changes are included in this PR?
copy_one_file
less urgently than default, so thatbackground_writes
are done with higher priority. Otherwisecopy_one_file
will keep buffering more data in memory without giving thebackground_writes
any chance to upload the data and drop it from memory. Therefore, without this large copies would cause OOMs.std::priority_queue
to implement the priority.arrow-acero-hash-aggregate-test
that fail if this property is not maintained. I'm not sure what is the correct option but for now I have ensured that tasks of the same priority are run in the order they are spawned.Are these changes tested?
Added some extra automated tests. I also ran some large scale tests copying between Azure and local with a directory of about 50,000 files of varying sizes totalling 160GiB.
Are there any user-facing changes?
CopyFiles
should now work reliablyThreadPool
now runs tasks in priority order